Set Permissions

CREATE, READ, UPDATE, DELETE, EXECUTE, ALTER, LANGUAGE (CRUDEAL) permissions can be set for any resource path in a VDB. A resource path can be as specific as the fully qualified name of a column or as general a top level model (schema) name. Permissions granted to a particular path apply to it and any resource paths that share the same partial name. For example, granting read to "model" will also grant read to "model.table", "model.table.column", etc. Allowing or denying a particular action is determined by searching for permissions from the most to least specific resource paths. The first permission found with a specific allow or deny will be used. Thus it is possible to set very general permissions at high-level resource path names and to override only as necessary at more specific resource paths.

Permission grants are only needed for resources that a role needs access to. Permissions are also only applied to the columns/tables/procedures in the user query - not to every resource accessed transitively through view and procedure definitions. It is important therefore to ensure that permission grants are applied consistently across models that access the same resources.

Permissions are not applicable to the SYS and pg_catalog schemas. These metadata reporting schemas are always accessible regardless of the user. The SYSADMIN schema, however, may need permissions as applicable.

To process a SELECT statement or a stored procedure execution, the user account requires the following access rights:

• READ- on the Table(s) being accessed or the procedure being called.
• READ- on every column referenced.

To process an INSERT statement, the user account requires the following access rights:

• CREATE- on the Table being inserted into.
• CREATE- on every column being inserted on that Table

To process an UPDATE statement, the user account requires the following access rights:

• UPDATE- on the Table being updated.
• UPDATE- on every column being updated on that Table.
• READ- on every column referenced in the criteria.

To process a DELETE statement, the user account requires the following access rights:

• DELETE- on the Table being deleted.
• READ- on every column referenced in the criteria.

To process a EXEC/CALL statement, the user account requires the following access rights:

• EXECUTE (or READ)- on the Procedure being executed.

To process any function, the user account requires the following access rights:

• EXECUTE (or READ)- on the Function being called.

To process any ALTER or CREATE TRIGGER statement, the user account requires the following access rights:

• ALTER- on the view or procedure that is effected. INSTEAD OF Triggers (update procedures) are not yet treated as full schema objects and are instead treated as attributes of the view.

To process any OBJECTTABLE function, the user account requires the following access rights:

• LANGUAGE - specifying the language name that is allowed.

See also:

• User management view

Reference manual pages:

• Data Roles
  • Permissions
  • Role Mapping
  • User, role and permission settings
  • System Functions